v2024-2025 Robo Yetis Team 5196 Engineering Portfolio

Background

The Robo Yetis founded in 2011 at Aspen High School has been the primary Aspen High School robotics

team for the past few years. Our oldest members are juniors with three years of experience. This was the

first year since the pandemic that our club had more than one team. While they are not at this

competition, the Robo Yetis are excited to announce their sister team the revived Black Forest Robotics

team. This season we have been working separately but our designs have become closer and closer. The

Black Forest team was not ready to compete at this qualifier so we invited some of their members to

come work with us. One thing the Robo Yetis would like to highlight this year is that the majority of our

team is in 8th grade. All of our eighth graders have had experience in FLL. We met them last year while

we were doing outreach at our middle school To get them adjusted to FTC the first thing we did was

build a GoBilda kit robot. That way our new members could learn how to use tools such as hex keys and

become more familiar with the size of the robot and its strategy goals. \

Gender Make UP

Club

Girls

Boys

Team Makeup

Girls

Boys

Grade Level Make Up

Club

8th

9th

10th

11th

12th

Team

8th

9th

10th

11th

12th

Team goals

Gracious Professionalism

Gracious professionalism is one of the main values of FTC. That is why we decided to bring more

attention to it by making it one of our goals. Another reason we wanted to highlight it this year is

because of our club split. We are now sharing our space and resources with another team. We thought

this might be a challenge since we would be roommates and competitors, so we did not want any

conflict. To practice gracious professionalism we first put in place a few strategies such as reorganizing

our room and making rules on when the teams can talk, so that no one feels like the other team is

holding them back or wasting their time. We also all started as a club at the beginning of the year. When

we first all met as a group we were not split into two teams. We took/gave tours of our space and began

to brainstorm ideas for this year’s challenge. We were successful in maintaining gracious professionalism

with the Black Forest Robotics team which can be seen in our collaboration with them at this

competition.

Collaborative Google image with BFR explaining our organization

Building interest

Like many other teams, the Robo Yetis were hit hard by the pandemic. We did not have anyone

competing for a while and then when our juniors joined three years ago there was only one senior. A lot

of the mentorship has been left to our juniors who didn’t receive much themselves. One of our goals has

been to start appearing in our community again and building more interest in the younger groups. When

we learned we could have 8th graders on our team we invited them to join us as a way to maintain and

grow the program. This just about doubled the size of our team.

Time Management

Last year we had to cram before every competition and it was very stressful and did not give us enough

time to make improvements to our robot or practice driving. As a result, time management was one of

our biggest goals. We used strategies such as a Gantt chart, Millanote, and a rule that we could not stay

past 6. Last year we had a few meetings go well into the morning. This year we have only broken our rule

twice where we stayed until 9:30. We are going to continue to work on this but our improvement from

last year has been drastic.

Gantt Chart

Millanote

Building strategies

Pre-Building

At the beginning of the season we had hoped to do more Computer Aided Design this year, but with our

team being mostly new members we did not have enough time to thoroughly teach our new members

how to use CAD to the level of detail we needed. As a result, we used our whiteboards and paper to

draw out our designs. We also acted out a lot of the necessary pieces with our arms or pieces we already

had to communicate what we needed to make.

Prototyping

We used paper and tissue boxes to prototype many of our nonkit parts. We made our bucket out of

paper and our claw out of cardboard the first time.

Building

When building we tried to split up into pairs and every pair had an assignment for the week on what

they had to build. That way if one person couldn’t come one day their partner would work on the

assignment. We made the assignments based on the level of commitment of the pairs. If we had a pair

that could only come one day each we would give them something like an actuator or a slide which is

part of a kit and has instructions.

Test as we go

Something new this year is we are testing all of our moving parts as we build. Last year we ran into the

problem of putting together our entire robot and then having some parts not turn on or move like they

were supposed to. It was then a big time expenditure to take those parts off fix them and then reattach

them. One of our outreach experts recommended that we run our actuators and slides before putting

them on the robot. We have employed this strategy and it has saved us a lot of time and given us

confidence in our robot’s ability to turn on and move.

Game Constraints

When designing anything it is first important to identify your constraints. That way you do not build

something that doesn’t follow the rules or waste time designing something that you can’t use.

Constraints:

Size

FTC has a size constraint of 18inx18inx18in for before the game starts. Once the game starts, we

can extend 1 foot outside of our frame and 4 feet above our frame.

To stay within the size constraints we built a chassis that was 17inX17in and tried not to build

outside of the chassis frame.

Number of Motors

Our original design had 9 motors, but the limit is 8 so we had to redesign and ended up only

using 7.

Time

Everyone on our team has other extracurriculars outside of robotics. This means the time

constraint for building is a huge limit for us. Our time constraint mainly plays into our game

strategy. We knew we would have to use a lot of past knowledge and skills since we did not have

much time to test new ideas. That is why we are going for a mid-level hang. We know how to

hang, but we have never had to pull our robot up and our robot is too big to be above the

bottom bar, so as a result of time we are going for a mid-level hang.

Materials

Shipping where we are is pretty difficult, so if you order something online it is not going to be

there within a week. As a result, we try to use materials that we already have. That means we

are partially constrained to what is in our parts closet. We design with those materials in mind.

Robot Design

Name of section: Chassis

Purpose: This is the base of our robot and the part that drives it. Besides driving it also aids in keeping

us within the size constraint.

Constraints: 18inx18in, 9 motors, materials in cabinet

Research: We used the outline of past chassis we have built and just changed it for size.

Picture

Name of section: Gears

Purpose: Move both of our linear actuators forward with the same motor, so that they move at the

same time. This prevents us from bending/breaking parts because they are moving at different

speeds. It will also help us when driving because the claw will go straight in front of the robot. The

actuators also move better and faster creating less strain on the battery.

Constraints: Size- Our first try stuck way out the end of the robot, so we had to disassemble the

actuators and chassis to move it forward.

Research: We used the ParkTools bike maintenance book to help us learn about chains.

Picture of final:

Name of section: Linear Actuator

Purpose: Move the claw out into the submersible and back into the robot for the handoff to the

bucket.

Constraints: Can not extend more than a foot outside of the frame

Research: We used one of these kits last year to hang and thought it would work well for this section.

We then used GoBilda’s videos and instructions to see how it works and how to build it.

Picture of final:

Name of section: Claw

Purpose: Pick up samples from within the submersible and then hand them back to the basket.

Constraints: Can not extend more than a foot. Needed to be able to go out and down and pick up

samples going both ways.

Research: We watched a video from FUN Robotics Network on YouTube, experience

Our first claw was a replica of the one from the YouTube channel, but we ran into some difficulties

connecting it to our robot in a way that would keep its base from rotating, so we decided to do

something more simple for our first competition and go with a claw very similar to last years.

Picture of final:

Name of section: Basket

Purpose: To catch the sample from the robot, take it up the slide, and then tip it into the basket

Constraints: has to fit with claw

Picture of final:

Name of section: Slide

Purpose: Move the basket and hanging mechanism up to the basket and hanging bar

Constraints: can not extend over 4 feet

Research: we used a GoBilda kit to build both of them

Picture of final:

Name of section: Hanging

Purpose: Move up with the slide and then latch on to the bar and hold it while the slide retracts.

Constraints: can not stick out the back of the robot.

Before we angled our slides we were going to need one that was much bigger and extended out the

back of the robot a lot. The robot swung a lot and we did not fit within the size constraints. Our new

one is much smaller and does not swing as much.

Pictures

First one

Revision

Name of section: Wire tract

Purpose: To ensure wires can extend and retract long distances linearly without becoming tangled or

caught on other robot components

Constraints: We cannot have loose wires on the robot, it needs to be linear, and it needs to extend the

length of the linear actuators

Description and diagram of how it works:

Wires fit inside of the tract, and they can fold around, so as the actuator extends, the fold point is

moved so the wires can extend further from the robot.

We first tried to use loose wires and realized

they would get caught and may damage the

robot or cause it to not function.

Adding the tract allowed us to move the wires

effectively without being caught and allowed a

compact solution that decreased mess and

tangling.

Picture of final:

Special Design

Wood

Last year we used many 3D-printed parts. We found that while they were light and relatively

easy to make, they broke a lot. This year with our fear of things breaking and our lack of

experience with CAD, we decided to go with wood for our special pieces. Wood is light and

strong. It is also easy to make multiple drafts or changes later. We used wood for our claw and to

attach our slides to our robot.

Claw

Our wood claw also uses veterinarian pet injury wrap as a way to grip the samples.

Basket

When testing how the basket would work we picked up the red container and used it as a

prototype. We then realized it was a perfect size and decided just to use it instead of spending

time cutting or printing something. It is lightweight and easy to attach.

Next Design

Before our next competition, we want to add another servo to our claw so that it is more stable and we

would like to alter our design so that we can get the high hang.

Game Strategy

What we are going to do-Marley

- Hang

- Species

- Specimens

- Reasoning for our decisions

- Includes pictures of what we are talking about (a lot of judges are not involved with FTC and just

volunteer so they may not know really what the field looks like and what parts are called)

After watching the video, we first identified that with such a young and experienced team we should try

to go for quality over quantity. We decided our robot must be able to place the samples in the top bin

and be able to do a mid-level hang. These both seemed attainable because the samples only required a

longer slide and we know how to hang from last year. We decided not to attempt the specimens

(hanging pieces) since they were not worth the extra points and would take more time. We plan to go

back and forth from the submersible to the baskets. We will extend our slide as we are moving to save

time. If for some reason we can not get our sample from our claw to our basket, we plan to put a sample

in the net zone (space taped off under the baskets) to score 2 points. Ideally, we will put our sample in

the top basket for 8 points. Then during the end period, we plan to do a mid-level hang earning 15

points. We are estimating at our first competition we will be able to back and forth from the submersible

to the basket 5-6 times. That means we will be scoring 55-72 of our alliance’s points.

Introduction

Programming a robot requires a significant amount of coordination between functions -

distance-aware movement functions must be able to interpret the location of the robot, which must be

corrected for overflow when sending data over wires, and the robot and controller must constantly be

isolated from static that can interfere with sent signals. We elected to synchronize the base of our robot

in the Robot class, which contains references to all of its parts: a Chassis, a set of Encoder localization

wheels, a Launcher, and others. The encoders are stored in the main robot model, and not the chassis,

because they are the basis of the robot’s action methods.

Localization

Localization, or knowing the location of the robot relative to its starting position, is the basis of

our coding system. We built three custom encoder pods that allow the wheels to always connect to the

ground, even when parts of the robot are raised, and attached three REV Robotics encoders to the main

control unit, feeding our code a constant stream of location data. Originally, our localization relied upon

the RoadRunner library, created by ACME Robotics (FTC Team #8367). However, despite RoadRunner

being a powerful library with many useful features, we determined that it would be best for the

functionality of our robot to use our own Encoder implementations. Our Encoder class relies on a

RoadRunner implementation to a certain degree, taken from the RoadRunner quickstart. We use this

implementation to fix overflow in the transmission of data from the encoders to the control unit - while

these data may be relatively accurate, the encoders have (ideally) incredible precision. This precision is

essential because the encoders are the basis for so much of our code design, and is the logic behind our

decision to use RoadRunner’s Encoder implementation. However, we do not use any other parts of

RoadRunner - we specialized the Encoder implementation to use inches instead of ticks, and all of our

movement methods take in an argument of distance in inches.

Robot Movement

Our robot’s autonomous mode relies on precise distance measurements provided by our

encoders. If an encoder makes an error of 0.01 inches/inch, it may not be immediately noticeable

(overflow can result in errors even larger than these, as entire bytes of velocity information can be lost).

However, if the robot moves 100 feet throughout the autonomous mode, then its encoder positioning

would be a foot off. If the robot were to try to pick up a pixel at that point, it would be unable to do so. It

is therefore essential for our encoders to be as accurate as possible. We have garnered specifications for

the wheels and encoder pods that we installed on our robot, and have tested movement continuously in

the real world. Our autonomous mode has a certain amount of error correction built in (though, at the

time of this writing, the autonomous mode is quite sparse), but focuses on specific movements only

allowed through knowledge of location, rather than a sort of detection method (ex. TensorFlow Object

Detection). Our manual control modes also rely on distance measurement but in an incremental way.

Our current forward movement methods rely on setting motor power, but we decided to create a new

recursive function while the robot runs to move forward. While the robot is running (while

(opModeIsActive())), we call the driveStraight method and other functions based on the current

percentage of tilt in the controller joysticks. These methods call the underlying Chassis.driveStraight with

a distance parameter of one inch - an amount small enough to allow finite movement, but large enough

to prevent high overhead. The function calls itself when the driveStraight method finishes, and checks if

the gamepad is still tilted - if so, it drives the robot again.

Currently, the driveStraight method pauses the robot at the end of its movement, using the stop

function (which sets all motor powers to 0). However, we have had to refactor this function so that it

only stops when the robot is truly done moving, rather than every inch, preventing “jerky” motion. We

have accomplished this by passing in a should stop parameter to the driveStraight function, which will

only be true if the robot has traveled enough.

Project Organization

Abstraction, or moving lower-level code to specific handlers, is a major feature of our project

structure. Our OpMode calls functions on our Robot model, which in turn calls its proper subpart. This

abstraction is to avoid having the OpMode contain references to any parts of the robot itself. This also

means that, when we have to change the actual behavior of a function (for example, changing the

distance parameter of movement functions from inches to feet), we can just change the lowest-level

function and then alter a slightly higher one to still take inches and then convert. We also abstracted

telemetry functionality to the Utils.OutputUtils.print function. This function avoids possible errors of

forgetting to use telemetry.update(), though it does increase overhead.

Pixel Detection

When we began to code our robot, we considered using a TensorFlow Neural Network for object

(pixel) recognition. However, we decided against using an AI to detect pixels for several reasons. Cameras

on robots are not only expensive, but also incur significant overhead, and an RGB camera would require

a large amount of power. The camera can also be destroyed or knocked off-kilter easily, which would

result in improper location detection for the pixels. The nature of Centerstage does not require a robot

to detect the vast majority of pixels in random locations - instead, the robot can find them in

predetermined spots around the field. An object detection Neural Network might also struggle with the

estimation of proper bounding boxes for objects, especially with novel backgrounds encountered at

competitions.

Outreach

Instagram

With the loss of all of our older members, this year came the loss of our social media passwords.

This led us to create a new Instagram account. If you would like to take a look our username is

@ahsroboyetis. We have used our social media to get our team out there. We first put all of our bios on

it, so followers could get to know us. We also update our Instagram page regularly by posting pictures of

our work and humorous captions. We followed other FTC teams and they followed us back. Through

DMs, we have made connections with other teams. We asked the teams who followed us where they

were and what competitions they were going to.

George Helfenstine

Our middle school FLL coach made an announcement at the middle school describing what we did and

encouraging middle school students to join our team.

Will Gilmore

While meeting with our local FLL teams we met one of the coaches, William Gilmore, who is a

mechanical engineer. After our presentation, he sent us an email asking if he could come in and talk to us

about our design and see if he could improve it. After meeting with him we decided that we could have a

static claw. He also brought us a McMaster-Carr physical catalog. In there, we can find any materials.

While looking at it, we learned that we should be using screws specifically for plastic. Gilmore was also

able to help us with our static issues, even though it is not his specialty. He taught us how to mount our

grounding wire properly. It was very beneficial for us to be able to hash out our design with someone

who knows enough about design that they can help us critique our plans. He has also offered to let us

use his 3-D printer which is a huge win.

FLL

Some of our members went to our middle school to help our Worlds Qualifying FLL team design their

project, which is a robot that looks like a turtle and swims through reefs to monitor reef health.

Betty Book-Sloane/Marley

One of our past teams wrote a book called Betty the Yeti. This year we are working on writing a sequel

that we can then read at our local library.

Clubs Fair

The main way our team attracts new members is at our school’s club fair. The fair happens every

mid-October. During our study hall period, clubs set up tables in the gym. Every year we sign up for a

table, make sure we have a robot for demonstrations and print out the sign-up sheets. This is a good

opportunity to remind our community about the robotics club and to get new students or freshmen

involved. Leading up to the club's fair we also post flyers around the school. We got four members this

fall after the club's fair.

Cover page

Background/make up

Team goals

Design process/build strategy

Game strategy

Design

- Chassis

- Slides

- Hanging

- Moving claw out

- Claw-Aurelia

- Basket (with chute)

Outreach

Non-technical

- Instagram

- Spotify

- Showing of robot

- Betty the yeti

- Clubs fair

- George helfenstines

- Logo competition-Aurelia

Technical

- Fll teams

- Will gilmore

- Tyson weighs

State goal

State constraints

Describe design

Research

What went wrong

Goals for next one

What went wrong

Goals for next one

Final description of how it works